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.  ’  We  have  constructed  a  local  eode  generator  for  the 
VAX-Ill  using  a  parser-Uke  instruction  pattern  mateber. 
The  code  generator  replaces  the  seeond  pass  of  the 
UNDCP  Portable  */C*f  compiler.  This  paper  describes  the 
design  of  the  eode  generator  and  the  special  considera¬ 
tions  imposed  by  the  pattern  matching  process.  We 
summarise  the  structure  of  tbs  machine  description 
grammar  and  its  associated  semantic  actions,  os  wall  as 
the  tools  we  developed  to  manipulate  the  large  VAX 
description.  In  our  experience,  this  approach  makes  the 
instruction  selection  phase  of  the  compiler  easier  and 
faster  to  implement,  and  more  Ukely  to  bo  eorroet  than 
traditional  techniques.  - — 


In  the  last  few  years,  we  have  been  studying  an 
approach  to  code  generation  in  which  instructions  are 
selected  by  a  pattern-matching  process  that  ebooees 
instructions  from  a  table  generated  automatically  from 
a  machine  description.  The  initial  version  of  the  tech¬ 
nique  is  described  in  [ClanvilleTT]  end  [GlaavilleTB]. 
[GrabamBO]  gives  an  overview  of  this  and  related  tech¬ 
nique*:  [Henryfll]  gives  a  detailed  description  of  an 
Implementation,  together  with  some  improvements  to 
the  method.  Related  work  appears  in  [ Canape thlBO], 
[JansohnSO],  [CuJralBl].  and  [Crawford S2]. 

Recently,  we  conducted  a  limited  experiment  to 
gain  more  experience  with  this  technique  [Schut- 
manR].  Our  goal  was  to  attempt  to  uoe  this  method  in 
a  controlled  setting  in  which  comparisons  would  be  pos¬ 
sible.  Our  experience  has  been  favorable  and  is 
described  in  this  paper. 
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«.  The  Kxpertmont 

The  UNIX  portable  *‘C"  compiler  (abbreviated  es 
PCC)  [Johns on 79]  is  a  retarg stable  compiler  for  the  sys¬ 
tems  programming  language  ”C*.  It  is  written  la  " C' 
and  runs  under  the  UNIX  operating  system.  PCC  has 
been  successfully  retargeted  to  over  two  docsn 
machines  [JohnsonBlj.  The  compiler  has  two  logical 
phases.  The  first  phase  is  mostly  specific  to  "C*\  and 
produces  an  intermediate  representation  of  the  pro¬ 
gram  consisting  of  a  forest  of  expression  trees  inter¬ 
spersed  with  target  machine  specific  instructions  to 
implement  unconditional  control  flow.  The  second 
phase  generates  assembly  eode  and  is  moetly  target 
mao  bine  dependent  driven  by  a  somewhat  od  toe  pat¬ 
tern  matcher  using  patterns  taken  from  a  hand  gen¬ 
erated  table.  PCC  does  no  global  optimisation  or  recog¬ 
nition  of  common  subexpressions.  A  Fortran  77  com¬ 
piler  [Feldman 79]  and  the  Berkeley  Pascal  compiler 
[Joy79]  share  the  same  intermediate  representation 
and  second  pass  of  the  portable  "C  oompUer. 

Our  experiment  w» .  to  replace  the  second  pass  of 
the  portable  "C*  compiler  with  a  eode  generator  that 
uses  the  Graham-Clan  villa  methods.  We  chose  to  pro¬ 
duce  eode  for  the  machine  we  had  available,  a  VAX-1 1. 
and  to  devote  only  a  limited  amount  of  time  to  the  pro¬ 
ject.  Our  initial  goal  was  not  to  develop  a  truly  retarget- 
able  compiler,  but  to  gain  experience  with  Graham- 
Clan  villa  techniques,  generating  good  local  code  for  a 
real  machine,  for  production  programming  languages, 
to  force  us  to  solve  real  problems.  By  comparing  our 
generated  eode  with  that  produced  by  PCC.  we  could 
analyse  the  effectiveness  of  our  implementation  deci¬ 
sions.  This  goal  has  been  achieved,  and  with  this  experi¬ 
ence  we  are  now  trying  to  make  the  eode  generator 
retargetabte  and  to  improve  its  performance. 

We  had  available  a  previous  implementation  of  a 
Grabam-Glanville  eode  generator  generator,  the  Code 
Generator  Generator's  Work  Station  (CCCWS)  [HenryOl]. 
However,  we  chose  to  discard  parts  of  it  The  CGCWS's 
internal  model  ef  instruction  descriptions  was  too  lim¬ 
ited:  It  ran  too  slowly  and  produced  tables  that  were  too 
large.  The  CGCWS’s  eode  generator  spent  too  much 
time  interpret!!*  cumbersome  tables  when  checking 
semantic  attributes.  When  we  began  the  experiment  we 
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wars  uncertain  hew  we  wanted  to  change  the  automated 
ae  man  tic  handling.  Consequently.,  we  eheee  to  pregram 
the  a  amen  tic  attribute  evaluator  ae  VAX-specific  rou¬ 
tine*  hand-ceded  in  "C".  rather  than  attempting  to  gen¬ 
erate  the  semantic  actions  automatically.  We  are  new 
eon  verting  to  program-generated  semantic  actions. 
This  change  will  make  retargeting  easier. 

We  were  able  to  reclaim  all  parts  of  the  CGCWS 
relating  to  the  syntactic  aspects  of  a  machine  descrip¬ 
tion  grammar,  ineluding  the  table  generator.  All  pieees 
of  the  CCGWS  dealing  with  semonMe  aspects  were  dis¬ 
carded. 

There  are  three  logical  parts  to  the  basic  Craham- 
Glanville  code  generation  technique.  The  target 
machine  description  (1)  la  fed  to  a  tabic  constructor  (2) 
in  the  cede  generator  generator.  The  constructed 
tables  then  control  an  instruction  pattern  matcher  (3) 
in  the  cede  generator.  The  first  two  parts  are  static; 
they  are  used  once  for  each  target  machine.  The  last 
port  is  dynamic,  invoked  for  every  program  being  com¬ 
piled. 

3.1.  Tssget  Machine  Deesriptlan 

In  the  Greham-GlanviUa  system,  instructions  on 
the  target  machine  are  described  as  attributed  pro¬ 
ductions  in  a  context  free  grammar.  There  is  one  non¬ 
terminal  in  the  grammar  for  each  class  of  registers  on 
the  target  machine,  and  an  additional  sentential  non¬ 
terminal.  In  addition,  there  can  be  non- terminals  for 
pseudo- registers  and  for  status  hits  or  condition  codes. 
The  terminal  symbols  In  the  grammar  are  the  node 
labels  in  the  expression  trass  for  which  code  is  to  be 
generated.  The  right  hand  sides  of  the  productions  in 
the  grammar  have  the  prefix  linearized  term  of  a  com¬ 
putation  tree  consisting  of  terminals  and  non¬ 
terminals.  The  left  hand  aide  designates  how  the  com¬ 
pute  tim  effects  the  processor.  In  the  original 
Craham-Glanville  formulation,  each  production 
describes  the  operation  performed  on  the  target 
machine  by  one  instruction,  together  with  one  combi¬ 
nation  of  addressing  modes  deooribing  the  operands. 
We  call  such  a  machine  description  grammar  /tat. 

For  most  examples  in  this  paper,  we  will  shew  the 
linearised  tree,  instead  of  the  graphical  representation 
of  the  tree.  Figure  1  describes  the  terminal  and  non¬ 
terminal  symbols  we  will  use  throughout  the  remainder 
of  the  paper  (exeept  far  the  Appendix).  By  convention, 
ail  terminal  ^rthboU  start  with  an  upper  ease  letter; 
non-terminal  symbols  begin  with  tower  ease  letters. 
Unless  specified  otherwise,  all  non-terminal  symbols 
are  nil-ary. 
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As  described  in  [GlanvUleTfi],  each  production  has 
associated  with  it  a  string  and  a  set  of  semantic  bind¬ 
ings  into  the  left  and  right  hand  sides  of  the  produc¬ 
tion.  The  string  and  bindings  are  used  to  construct  the 
assembly  cede  representation  of  the  generated 
instructions.  In  addition,  each  symbol  on  the  right 
hand  side  may  have  semantic  qualifications,  all  of 
which  must  be  met  before  that  pattern  is  selected. 
For  example,  the  semantic  qualification  may  require  a 
constant  to  be  in  a  specified  range  (implementing  a 
range  Idiom),  or  require  a  constant  or  register  to  be 
the  same  one  referenced  in  another  part  of  the  pro¬ 
duction  (Implementing  a  Mndbig  idiom).  As  the  reader 
will  see,  semantic  qualification  is  handled  differently  in 
our  eode  generator. 

U  Table  Caaetnsoter 

The  machine  desortption  grammar  to  processed  by 
a  tabla-f  enerating  program  similar  to  an  SLPf  * )  parser 
generator.  Moot  machine  description  g.-  re  are 
highly  ambiguous,  sines  the  target  meet  *.*u- 

ally  implement  an  expression  in  many  difi.  «. 

The  table  generator  disambiguates  the  graaui:  by 
fhvering  a  shift  ever  a  reduce  in  a  shift/ reduce 
conflict,  and  a  reduction  by  the  longest  possible  rule  in 
a  rodnao/rednee  conflict  Thus,  the  table-driven  pat¬ 
tern  matcher  implements  the  maximal  munch  method 
[CatteUfiO]  in  wbleb  the  largest  possible  pattern  to 
matched.  If  there  era  two  or  more  longest  rules,  then 
the  Uhls  generator  eenaot  statically  choose  among 
them.  In  that  ease,  the  pattern  matcher  will  choose 
among  them  dynamically  using  semantic  attributes. 

The  table  generator  contains  algorithms  to  ensure 
that  the  pattern  matcher  will  not  get  Into  a  looping 
configuration,  whore  non-terminal  chain  rules  era 
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cyclically  reduced.  Tba  table  generator  alao  ebaek*  if 
there  it  tom*  input  for  which  the  pattern  matcher  will 
perform  an  error  action,  alto  called  a  syntactic  Meek. 
In  this  cate,  the  preient  table  generator  only  notifies 
the  utar.  and  doet  not  attempt  corrective  action. 

In  addition,  tba  table  generator  looka  for  patterns 
which  eon  be  used  only  if  a  aemantic  condition  it  mot. 
In  general,  the  input  cannot  be  guaranteed  to  satiety 
such  a  condition.  Therefore,  in  the  event  of  tueb  a 
semantic  Mock,  the  table  generator  constructs  a 
dt/ou U  action  alternative  from  other  productions. 
That  default  alternative  typically  causes  more  than  one 
instruction  to  be  generated. 

3.3.  Pattern  Kateher 

The  instruction  pattern  matcher  is  a  table-driven 
shift/ reduce  parser,  invoked  once  for  each  expression 
to  be  compiled.  Each  reduction  corresponds  to  one 
logical  instruction4  emitted  in  linear  time  in  a  provably 
correct  order.  Since  the  pettern  matching  and  table 
construction  algorithms  are  based  on  a  well  under¬ 
stood  model,  and  the  tables  are  constructed  automati¬ 
cally  by  a  provably  correct  algorithm  [Gian villa  78].  the 
only  source  for  error  In  constructing  the  Instruction 
selector  is  in  the  machine  description  or  the  support¬ 
ing  semantic  routines. 


4.  Modifications  to  the  Basic  algorithm 

We  find  that  because  of  the  richness  of  the  instruc¬ 
tion  set.  a  flat  machine  description  grammar  for  the 
useful  VAX  instructions,  mitten  using  only  the  register 


and  the  sentential  non-terminals,  would  have  ever  8  mil¬ 
lion  productions.  In  order  to  write  and  process  a  feasi¬ 
ble  VAX  description,  the  description  grammar  must  be 
/defend,  fn  a  factored  grammar,  additional  non¬ 
terminals  group  together  symbols  heving  a  common 
Amotion  throughout  the  grammar.  Tb  preserve  the  pro¬ 
perties  of  the  pattern  matcher,  only  two  kinds  of  factor¬ 
ing  are  considered:  factoring  of  complete  subtrees  and 
teetering  of  operator  symbols  into  classes.  Thus,  in  a 
factored  grammar,  each  right  hand  side  is  either  a 
flattened  tree  or  a  single  operator  symbol. 

Not  every  production  In  this  factored  grammar 
causes  code  to  be  emitted.  Productions  now  either 
encapsulate  phrases  (subtrees),  emit  instructions,  or 
serve  as  flue.  In  the  factored  grammar,  a  non-terminal 
no  longer  has  a  simple  semantic  attribute,  as  it  did  in 
the  flat  grammar  when  It  could  only  be  a  register.  With 
the  freedom  to  factor,  there  are  now  many  more 
choices  to  make  when  writing  the  grammar  and  imple¬ 
menting  the  semantics.  We  will  describe  the  design 
decisions  for  the  VAX  grammar  and  aemantic  attributes 
wo  used  after  we  outline  the  phase  structure  of  the  code 
generator. 


A  Code  Osnssatar  Organisation  and  Bata  Plow 

In  order  to  eater  to  the  needs  of  the  parser-driven 
pattern  matcher,  our  code  generation  phase  la  one  sin¬ 
gle  program  structured  into  logical  subpbaaes.  as  shown 
in  figure  l  Roughly  one  half  the  code  generation  time 
la  spent  in  the  pattern  matching  phase.  We  now 
describe  the  phases  in  more  detail. 
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la  the  first  phase.  aaeh  expression  trss  Car  which 
coda  is  to  be  generated  is  transformed  to  nuke  eode 
generation  easier.  Some  of  these  transformations 
adght  mere  properly  be  dene  by  the  first  pass  of  the 
"C*\  Pascal  or  Fortran  compilers.  However,  we  ehoss 
net  to  modify  the  existing  “front  ends'*. 


fi.1.1.  Phane  la:  bpilett  Central  Plow 

The  short  circuit  operators  in  “C”  (hit  and  R) 
contain  lmpUcit  control  flew.  Subtrees  with  these 
operators  are  rewritten  to  make  the  Implicit  toots  and 
conditional  branches  explicit.  Sub-trees  describing 
function  calls  are  replaced  by  compiler  generated 
temporaries  so  that  context  switching  dees  not  occur 
within  expression  tress.  A  use  of  such  s  temporary  is 
preceded  by  an  axpraaalan  tree  which  assigns  the 
result  of  the  function  evaluation  to  the  temporary. 
(Thus,  function  calls  are  no  longer  embedded  in  mere 
complex  expressions.)  Seth  of  these  transformations 
are  target  machine  independent. 

Are  additional  control  flew  transformations  are 
motivated  by  the  architecture  of  the  VAX.  The  first 
removes  selection  operators  from  the  tree.  The  selec¬ 
tion  operators  tost  a  boolean  value  and  evaluate  one 
of  two  possible  expressions  for  the  value  of  the  selec¬ 
tor.  A  transformation  makes  the  conditional  branches 
explicit.  Second,  a  truth  value  re  presenting  the 
result  of  a  comparison  must  be  constructed  by  a 
sequence  of  tests.  Jumps  and  aaaignmants.  sines  the 
VAX  lacks  an  instruction  to  construct  such  a  value. 
The  tree  is  rewritten  to  insert  the  more  primitive 
operations. 

These  operators  arc  rewritten  in  phase  ana 
because  we  wanted  to  isolate  all  issues  of  control  flow 
to  the  tree  rewriting  phase.  Unfortunately,  the  latter 
two  transformed  computations  aaeh  need  a  tem¬ 
porary  register.  Therefore,  the  first  phase  requires  a 
register  manager  that  la  totally  disjoint  (ram  the 
register  manager  in  the  third  phase.  This  tradeoff 
asada  to  be  reevaluated:  eee  (5.3.3. 


lams  additional  transformations  arc  motivated 
by  the  particular  target  machine.  Rewriting  la  noose- 
aery  to  expand  Intermediate  language  operators  hav¬ 
ing  no  corresponding  hardware  operator  on  the  target 
mac  Irina.  Unsigned  arithmetic  operators  art  typieal 


Vs  also  rewrite  Uw  tree  to  reorder  certain 
groups  of  operands  and  repines  particular  computa¬ 
tions  by  others  so  that  fewer  patterns  are  needed. 
Tlrie  enwewfeeffeeffen  reduces  the  number  of  patterns 
sigaifleaaUy,  especially  those  describing  addresses, 
hr  example,  left  shift  by  e  constant  is  replaced  by 
multipiienUea  by  the  appropriate  power  of  t.  subtrac¬ 
tion  by  n  sonetaat  le  replaced  by  an  addition,  and  a 
eenstant  operand  eirild  of  on  addition  operator  Is 
thread  te  be  the  left  eMM.  Ve  ocuM  also  perform  een- 
staat  folding  at  this  point,  but  we  easume  that  the 


Before  instructions  ars  selected  for  an  sxpres- 
rion  tree,  the  portable  “C*  compiler  reorders  the 
tree,  using  two  goals  motive  tad  by  (the  techniques  In 
(Sethi  70].  The  first  goal  is  to  minimise  the  register 
requirements  for  evaluating  the  expression  tree.  Tbs 
anaoad  goal  is  to  discover  subexpressions  whose 
•valuation  will  a  suss  subsequent  register  spilling  and 
to  Insert  explicit  stores  to  compiler  generated  tem¬ 
poraries  to  ovoid  the  spill.  By  handling  the  situation 
in  advenes,  the  eode  selector  will  never  run  out  of 
registers.  Since  in  the  portable  "C”  compiler  reord¬ 
ering  la  distinct  flroa  instruction  selection,  coordina¬ 
tion  la  lass  than  perfect,  and  is  a  source  of  many 
errors  in  retargeting  PCC  [JohnsonBl].  Nevertheless, 
the  attempt  to  prevent  spilling  is  a  good  idea.  The 
expression  reordering  in  PCC  occurs  in  its  second 
pees  end  is  therefore  not  reflected  in  the  input  to  our 
eode  generator. 

Bines  the  instruction  selector  in  our  eode  genera¬ 
tor  dote  a  left  to  right,  no  backup  traversal  of  the 
expression  tree,  unpredictably  allocating  registers,  it 
la  possible  that  a  mostly  right  recursive  tree  could 
run  out  of  registers.  However,  an  equivalent  left 
recur  alee  tree  might  not  have  this  problem.  Since 
"C".  Pascal  and  Fortran  do  not  specify  an  operand 
evaluation  ordering,  wa  introduced  a  simple  reorder¬ 
ing  heuristic  to  the  first  phase  of  our  eode  generator. 
The  heuristic  is  to  assume  that  the  more  complicated 
subtree  of  a  binary  operator,  and  hence  the  one  that 
should  bo  the  left  subtree,  is  the  subtree  with  the 
moat  nodes.  The  subtrees  era  swapped  according  to 
this  measure,  and  if  the  binary  operator  is  not  com¬ 
mutative  (assignment,  subtraction  and  division  are 
examples),  than  it  is  replaced  by  a  new  operator  that 
tails  the  third  phase  of  the  coda  generator  to  order 
the  computed  values  property.  In  our  experiment, 
adding  these  reverse  binary  operators  inereesed  the 
rise  of  the  grammar  by  3SX,  Increased  the  size  of  the 
tables  by  flfifl.  but  affected  register  allocation  in  less 
than  IX  ef  the  expressions  in  one  sot  of  "C"  pro¬ 
grams.  These  statistics  reflect  both  the  simple  nature 
of  "C"  express! one,  and  the  preexisting  loft  recursive 
bias  ef  compiler-generated  expression  trees. 

The  flret  phase  of  our  eode  generator  will  dis¬ 
cover  those  subtrees  which  wifi  always  require  regis¬ 
ter  spiffing  on  the  VAX,  by  virtue  ef  the  operation 
being  performed.  However,  beeauoe  ef  register 
management  complexity  Issues,  the  first  phase  eon 
not  know  whieh  values  mfpAf  be  spilled  Since  func¬ 
tion  eaUs  end  structure  or  record  assignment  always 
re  quire  spOla,  the  first  phase  factors  them  out  of 
expressions  end  replaces  them  with  references  to 
compiler  temporaries.  The  register  manager  in  the 
third  phase  le  prepared  to  spill  registers  Into  tem¬ 
poraries  on  the  fly. 


The  aoeead  phase  is  the  pattern  matcher.  Within 
the  pattern  msteber,  cash  encapsulating  reduction 
condenses  Uw  semantic  attributes  ef  the  pattern  into 
n  sfyuafura  associated  with  the  left-hand  side  non- 
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terminal.  Typically,  these  reductions  correspond  to 
addressing  modes.  Shies  ths  other  phases  neither  can. 
nor  ebould.  predict  bow  the  pattern  matcher  will  make 
these  oendaneatioea.  all  communication  from  the 
preceding  tree  transformers  to  tbo  foUowtng  soman  tic 
phase  is  throogb  the  semantic  attributes.  This  conven¬ 
tion  oan  be  a  logical  bottleneck.  Other  reductions  are 
either  for  paning  purpoaas.  or  eauea  one  or  mere 
instructions  to  bo  omitted  by  the  subsequent  phase. 

IJ.  Thaos  n  hekwMm  O - dka 

Tbs  majority  of  the  work  in  the  post-pattern* 
matching  phase  performs  relatively  uninteresting 
housekeeping  shores.  The  interesting  parts  are  the 
semantic  aspects  of  instruction  selection  and  genera¬ 
tion.  and  rogistor  allocation. 

As  a  precondition  to  entry  into  the  instruction 
generation  phase,  the  syntactic  pattern  has  selsetod  a 
syntactic  pattern  for  a  three  address  instruction.  That 
pattern  may  correspond  to  more  than  one  choice  of 
instructions  or  pseudo  instructions,  depending  on  the 
semantic  restrictions.  Tbs  pattern  matcher  can, 
therefore,  be  regarded  as  an  instruction  schema.  If  it 
was  necessary,  the  pattern  matsber  has  also  forced 


generic  destination  1st  source  tad  source 
operator  operand  operand  operand 

ADD  <U  e(fpj>  <L  ll?>  <L.  a(fp)> 

(Mere.  "a(fp)M  is  the  assembler-  syntax  for  sari- 
able  ”a“.  “llT*  is  the  assembler  syntax  tor  the 
Immediate  constant  “IT*,  and  "L“  stands  for  the  data 
type  long.) 

Initially,  the  first  Una  in  the  Instruction  table 
entry  Is  found.  The  idiom  recognitor  may  then  select 
the  second  or  third  line  in  the  instruction  cluster.  Vs 
will  return  to  this  stem  pis  in  tbs  next  section. 

If  semantic  blocking  were  poacibic  tor  o  given 
instruction,  the  Instruction  selector  would  first  chsck 
the  semantic  restrictions  causing  blocking.  If  there 
wars  a  semantic  block,  the  selector  would  then 
replace  the  given  instruction  by  a  default  list.  How¬ 
ever,  our  VAX  description  does  not  contain  any  seman¬ 
tic  blocks. 

If  the  destination  wore  an  assignable  register, 
instead  of  a  memory  location,  than  the  register 
manager  would  bo  oaliod  at  this  point  The  assigned 
register  would  ho  encapsulated  into  an  addressing 
mods  descriptor,  and  the  general  instruction  telec* 


the  Instruction's  operands  to  be  converted  to  the 
appropriate  data  types 

Instruction  selection  is  driven  by  the  (elected 
syntactic  pattern,  and  by  the  information  stared  In  a 
hand  written  fnafruefton  table,  bah  entry  in  the 
instruction  tabic  distinguishes  among  different 
instructions  haring  the  same  syntactic  description, 
end  epeclfles  the  description  of  cosh  instruction  that 
can  be  emitted.  An  entry  In  this  table  Is  chosen  baaed 
on  the  generic  operator  and  the  typee  of  its  operands. 

Figure  3  shows  tbs  table  entry  tar  addition  of 
longs  Tbo  "op”  field  Is  the  operator  name.  The 
Arid  is  the  number  of  operands  required  by  the  opera¬ 
tor  and  the  "print"  field  is  tha  assembler  mnemonic 
tor  the  instruction.  Tha  "binding”  field  specifies  the 
binding  idiom  (an  operator  name),  the  ‘w*  field 
indicates  whether  the  scores  operands  can  he 
swapped,  and  tha  "range"  field  specifies  the  internal 
name  for  a  range  idiom. 


a  s  an  -sa-  ap-g-ca 

ADD  t  LONG  "adder  null  no  I~*dd2 

DfC  1  LONG  "tael"  null  no  null 

Hg — .  — j — j-g  "Till  s 


Vben  requested  to  gaasrata  sods  tor  the  (atypi¬ 
cal)  "C”  assignment  expression 

a  •  IT  ♦  a; 

tha  Instruction  selector  la  presented  with  the  syntac¬ 
tic  pattern  tor  a  three  address  add  instruction.  and 
thaao  semantic  descriptors  tor  the  operator  and  tha 


tion  mechanism  would  be  called. 

Vc  recognise  two  classes  of  idioms,  binding 
idioms  and  range  idioms.  A  binding  idiom  determines 
whether  one  of  the  source  operands  matches  tha  des¬ 
tination  operand,  aa  one  precondition  for  turning  a 
three  address  instruction  into  a  two  address  Instruc¬ 
tion.  A  range  idiom  checks  whether  one  of  tbo 
aourcet  to  the  instruction  is  a  constant  In  a  particu¬ 
lar.  poasibiy  degenerate,  range.  Binding  Idioms  are 
always  cheated  before  range  idioms.  Thera  is  one 
range  idiom  associated  with  each  VAX  instruction  that 
oan  ba  simplified.  The  range  idioms  are  implemented 
by  functions  written  in  “C";  those  functions  follow  a 
relatively  straightforward  coding  stria. 

Let  us  new  return  to  tbo  example.  The  binding 
idiom  (ADD)  checks  that  ana  of  the  sources  matches 
tbs  destination.  Cither  source  will  do,  as  specified  by 
the  'W*  field  in  the  instruction  tabic.  Since  the 
second  source  matches  the  destination,  the  two 
operand  variant  is  used.  Tha  two  operand  variant  has 
no  binding  idiom,  hut  there  ia  a  range  idiom  associ¬ 
ated  with  the  adiflt,  so  the  range  idiom  is  triad.  That 
idiom  determines  whsthsr  the  other  source  la  a  literal 
with  tha  value  ana;  if  sc.  tha  tael  instruction  would  be 
used.  Shies  in  cur  example  the  test  toils,  tbs  *ddU2 
instruction  is  emitted  Instead. 

Sine*  wa  have  the  mechanisms,  it  is  convenient 
to  have  tha  idiom  reeognlsor  catch  certain  pieudo- 
taatruotlons.  The  previous  phases  incorrectly  assume 
that  the  VAX  can  implement  these  pseudo- 
Instructions  In  one  machine  instruction.  These 
pseudo-instructions  include  signed  integer  modulus, 
which  requires  a  register  to  hold  an  intermediate 
remit,  and  unsigned  division  which  requires  a  ceil  to  a 
library  function  that  is  known  not  to  modify  my 


registers.  These  operators  art  not  rewritten  using  the 
imnl  mechanism  is  tba  first  phase.  because  they 
vara  net  anticipated  In  the  design  of  that  phase. 

filth  the  eaoepUon  of  pseudo- las truotioo  expan- 
Sco,  the  idiom  raeegaisar  sub-phase  is  optional  in  tbs 
sense  that  if  it  were  omitted,  correct  oode  would  still 
he  generated.  Many  of  the  eboiees  mads  by  this 
phase  eouid  instead  bo  made  by  a  more  general 
peephole  optimissr,  presided  that  register  assign¬ 
ment  had  not  already  been  dona. 

The  register  manager  is  extremely  staple  and 
unsophisticated.  The  conventions  for  register  usage 
established  by  the  portable  “C"  compiler  divide  the 
registers  far  the  VAX  into  dsdicafod  registers,  which 
ere  assigned  by  the  first  pass  of  PCC,  and  the  ailecat- 
able  registers,  which  are  assigned  by  our  register 
manager.  The  register  manager  in  this  phase  supplies 
assignable  registers  upon  demand  from  other  routines 
in  the  instruction  generator. 

Since  there  is  no  detection  of  common  sub¬ 
expressions  (except  those  with  very  short  lifetimes 
created  by  the  tree  transformer),  the  least  recently 
used  register  is  also  the  register  with  the  most  distant 
future  use.  Consequently,  the  registers  ean  he 
assigned  and  freed  with  a  stack  discipline.  Vhen  an 
assignable  register  is  requested  as  a  destination  for  a 
particular  instruction,  the  register  manager  attempts 
to  reclaim  and  reuse  assignable  registers  from  the 
souree  operands  to  the  instruction,  railing  that,  the 
neat  free  register  is  selected.  If  there  is  no  ellocat- 
abla  register  available,  e  register  from  the  bottom  of 
the  staek  is  spilled.  Registers  are  always  spilled  to 
compiler  generated  variables,  fie  sail  memory  loca¬ 
tions  holding  spilled  values  virtual  refisfscs.  to  distin¬ 
guish  them  from  pUpofeaf  registers. 

K  a  register  is  spilled,  it  is  reloaded  Just  before  it 
is  used,  since  the  register  manager  cannot  determine 
whether  in  a  given  context  an  alternative  instruction 
could  have  fete  had  the  operand  directly  from 
memory*.  No  attempt  is  made  to  remember  register 
contents  in  order  to  replace  (etches  of  eopiss  from 
memory  or  to  avoid  spills  vhen  copies  already  sxist  in 
memory. 

Recall  that  register  assignment  is  also  performed 
whan  rewriting  trees  In  the  first  phase  (|5.1.3). 
Despite  logical  separation,  both  phases  allocate  regis¬ 
ters  from  the  same  hardware  register  bank,  so  the 
eOeots  of  register  assignment  performed  in  the  first 
phase  must  be  eemmuniested  to  this  phase.  The  first 
phase  generates  special  trees  specifying  which  regis¬ 
ters  It  assigned,  as  well  as  a  use  count.  The  descrip¬ 
tion  grammar  has  special  productions  to  match  these 
trees,  and  the  register  manager  in  this  phase  adjusts 
Its  Internal  model  accordingly. 

fie  successfully  ran  and  developed  the  code  gen¬ 
erator  for  months  without  finding  a  "C”  or  Pascal  pro¬ 
gram  that  ran  cut  ef  registers.  Consequently,  it 
seemed  unimportant  to  implement  better  register 


management  techniques,  finally,  the  demands  of  cer¬ 
tain  Fortran  programs  required  us  to  implement  this 
dmpla  term  of  register  spill  end  unspill. 

•.4.  Phone  4:  Output  Qoaaratian 

Instructions  are  formatted  int^  their  assembly 
cods  representation  by  consulting  two  tables.  The 
“print**  field  in  the  instruction  table  (figure  3)  defines 
the  operator.  Each  operand  is  printed  by  consulting  a 
hand  written  addressing  mads  format  fable,  which  is 
net  described  here. 

«.  Grammar  and  Code  Deaerator  Design  Details 

fie  now  examine  issues  in  the  grammar  and  code 
generator  design,  in  particular,  aide  effects,  the  gram¬ 
mar  structure,  the  augmented  grammar,  our  method 
for  handling  type  eon  version,  and  finally  the  problems 
we  had  "rounding  out*’  the  code  generator  to  accept 
the  entire  “C“  language.  These  issues  relate  to  all 
phases  of  the  cods  generator. 

If  an  instruction  produces  useful  results  in  two  or 
more  locations,  then  the  basic  Craham-Clanville  algo¬ 
rithms  ean  only  track  one  result  The  other  result 
must  be  ignored,  unless  the  computation  has  been 
flagged  in  the  input  to  the  code  generator  as  a  kind  of 
common  sub-expression.  Failure  to  exploit  ouch 
multi-valued  expressions  ean  result  in  cade 
inefficiency  tor  both  auto-increment  and  auto- 
decrement  side  effects  on  registers  (both  are  classed 
as  the  BMfofne  addressing  mode),  and  for  tracking  the 
ooodltion  codes  that  are  set  by  most  Instructions  fie 
are  able  to  modal  autoine  and  condition  codec  by  per¬ 
forming  either  souree  language  driven  recognition,  or 
extremely  simplified  data  flow  analysis.  For  **C"  pro¬ 
grams  on  the  VAX.  we  generate  acceptable  code. 

fie  are  currently  examining  the  possibility  of  using 
a  code  generator  that  does  not  recognise  autoine  or 
condition  eodes,  together  with  a  peephole  optimissr 
with  data  flow  analysis  [Davidsonfil]  [CiegerichSZ).  The 
peephole  optimissr  would  introduce  autoine  and  condi¬ 
tion  code  improvement  where  possible.  That  organiza¬ 
tion  would  simplify  more  ports  of  the  oode  generator 
than  the  following  discussion  suggests. 

Tbs  peephole  optimissr  strategy  would  still  not 
model  either  the  extended  divide  instruction,  which 
computes  both  a  quotient  and  a  remainder,  or  the 
string  instructions.  However,  using  both  quotient  and 
remainder  would  bo  appropriate  only  if  the  source 
language  provided  a  multi-valued  divide  operator,  or  if 
data  flow  analysis  revealed  that  both  values  were  used. 
Neither  ef  these  situations  are  possible  in  the  com¬ 
pilers  undet  discussion.  [MorganfiS]  discusses  string 
instructions  in  s  companion  paper. 

In  the  present  oode  generator,  we  generate  the 
autoine  addressing  mode  only  to  modify  dedicated 
registers,  and  then  only  if  the  dedicated  register  is  the 
destination  ef  a  postfix  increment  or  prefix  decrement 
binary  operator.  These  operators  are  in  the 
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intermediate  lenguags  only  if  they  are  la  the  eouree 
language.  finding  other  opportunities  far  eutoine 
eataile  date  Sow  aaelyeia.  [GanapathiBl]  discovers 
ways  to  uee  eutoine  by  e  poet  enelyeie  of  heeie  block*. 

The  semen  tie  descriptor  for  eutoine  must  be  han¬ 
dled  carefully  to  prevent  the  side  a  Sect  from  occurring 
more  than  once:  after  the  first  uss  aad  side  afloat,  the 
descriptor  is  modified  so  any  subsequent  reference  will 
refer  to  the  same  location*. 

On  the  VAX  almost  every  Instruction  sets  tbs  con¬ 
dition  codes,  usually  as  a  side  effect.  Consequently,  if 
a  condition  code  value  is  to  be  used  for  a  conditional 
branch  (the  only  possible  uee).  that  use  must  follow 
immediately.  Therefore,  our  code  generator  can  han¬ 
dle  condition  codes  syntactically  without  the  multi¬ 
value  tracking  problem  we  alluded  to  earlier. 

In  tect.  because  of  the  immediacy  of  condition 
code  use.  condition  codes  are  not  explicitly  refleeted 
in  our  machine  description,  for  example,  an  add 
instruction  which  puts  its  value  into  a  register  might 
have  the  description: 

rag  -  Plus  rval  rval  "aid!  rval.  rval.  rsg” 
where  “rval"  denotes  an  addressing  mode.  As  a  side 
effect,  the  instruction  sets  the  condition  code.  A  con¬ 
ditional  branch  instruction  which  tests  the  condition 
code  is  described  by: 

•  -*  C branch  Cmp  reg  Zero  Label  “jCmp  Label” 

Hare  terminals.  "Cmp”  and  "Zero'*  describe  the  par¬ 
ticular  condition  of  interest  and  “reg"  implicitly  refers 
to  the  condition  code  setting.  Thus,  the  pattern 
matcher  automatically  determines  from  context 
whether  the  Instruction  was  executed  for  Its  condition 
cede  setting  or  not. 

Ve  developed  the  initial  machine  deacription 
grammar  by  factoring  address  subtrees  and  operator 
classes.  This  initial  grammar  was  ever  factored,  caus¬ 
ing  incorrectly  resolved  shtft/rednae  conflict*,  leading 
to  incorrect  or  inefficient  code.  The  grammar  also  had 
syntactic  blocks.  Both  problems  were  solved  by  adding 
productions  to  the  initial  grammar. 


addressing  modes.  Consequently,  the  initial  grouping 
eauaed  many  mift/raduoe  conflict*  of  the  (simplified) 
form: 

[  displ  *  Phis  •  constant  reg  ] 

[  binop  «  Plus  >  ] 

A  decision  to  fitft  in  this  stats  is  tantamount  to 
deciding  that  the  "Plus"  will  be  implemented  by  the 
addressing  hardware  a*  a  displacement  address 
("dtspl").  rather  than  by  an  add  instruction.  The 
decision  is  premature,  and  could  lead  to  a  syntactic 
block,  although  not  in  this  simple  example.  To  avoid 
this  problem.  "Pius”  aad  “Mul"  cannot  be  factored  as 
a  "binop".  although  that  factoring  is  valid  for  “Or" 
aad  "Xor". 

The  example  describing  condition  codes  in  |8.1  is 
also  over  factored.  There  is  a  production,  not  previ¬ 
ously  shewn. 

reg  -  Dreg  (no  code,  just  condense] 
that  allows  dedicated  registers  to  be  used  every  whet  c 
assignable  registers  can  be  used.  This  production 
does  net  generate  eode.  and  so  the  condition  codes 
are  not  eat,  contrary  to  the  assumption  about  tbs 
non-terminal  "reg"  in  the  first  general  pattern: 

•  •»  Cbranch  Cmp  reg  Zero  Label  "JCmp  Label" 
TO  solve  this  problem,  we  added  a  new  production: 

•  -•  Cbranch  Cmp  Dreg  Zero  Label 
"tatl  Dreg:  JCmp  Label" 

This  ehange  circumvents  the  factoring  in  this  context, 
since  the  choice  of  a  shift  over  a  reduce  will  force 
selection  of  the  second  "Cbranch"  pattern  for  a  dedi¬ 
cated  register,  rather  than  the  first  Notice  that  we 
still  have  the  advantage  of  factoring  in  other  register 
contexts. 

Meat  of  the  outstanding  bugs  in  our  eode  genera¬ 
tor  are  caused  by  remaining  instances  of  everfactor- 
tag.  Ve  are  developing  a  factoring  theory  to  help  us 
find  aad  repair  these  eases  automatically.  Ve  have 
not  yet  invested  the  time  to  implement  tools  and 
redesign  the  grammar  to  avoid  overfaetoring.  How¬ 
ever,  we  foal  there  is  nothing  inherently  difficult 
about  writing  machine  grammars  to  avoid  these  prob¬ 
lems. 


fi.fi.1.  Overfaeterod  Grammar 

As  an  example  of  overfoetoriag.  our  initial  factor¬ 
isation  grouped  the  operators  "Plus".  "Mul”.  "Or”, 
and  "Xor"  together  into  a  special  operator  non¬ 
terminal.  called  "binop".  This  new  non-terminal 
replaced  the  operator  in  occurrences  in  which  it  was 
the  primary  operation  of  the  instruction.  Ve  chose 
this  factorisation  to  reduce  the  number  of  states. 
This  teetering  seemed  to  make  sense,  sines  these 
operator*  are  all  binary  and  commutative,  have  ident¬ 
ical  operand  semantics,  aad  are  implemented  in 
essentially  the  same  way.  However,  "Plus”  and  "Mul" 
also  ooeur  in  contexts  in  the  grammar  in  which  they 
ere  secondary  operations,  tor  example  within 


U.t  Syntactic  Booking 

Ve  also  had  to  add  productions  to  alleviate  syn¬ 
tactic  blocks  (error  productions).  Syntactic  blocks 
occur  in  long  productions  because  coding  alterna¬ 
tive*,  expressed  as  shared  left  context  in  a  given 
state,  are  insufficient  to  handle  all  eases.  To  prevent 
syntactic  blocking,  we  added  bridge  production*  to 
the  grammar.  A  bridge  production  shares  left  context 
to  the  point  of,  or  slightly  preceding,  a  syntactic 
block.  A  bridge  production  does  net  correspond  to  a 
single  instruction  or  addressing  mode.  However,  it 
will  handle  the  more  general  continuation  of  the 
feared  prefix. 
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Tha  following  two  productions  show  bow  tbo 
bridge  productions  or*  used.  Tbo  troa  form  of  tbo 
right  bond  aides  is  in  Figure  4;  the  linearized  form  is 
shown  below. 

block:  dz  -•  Plus  Plus  Const  rag  Mul*  Four  rag 

bridge:  re g  -  Plus  Plus  Coast  reg  reel 

The  first  production  describes  the  address  com* 
putation  performed  by  the  displacement  Indexed 
addressing  mode:  note  that  the  computation  performs 
an  implicit  multiplication  by  four.  However,  there  is  a 
syntactic  black  in  this  production  at  the  loft  subtree 
of  the  "Mul”,  indicated  by  the  since  other  argu¬ 
ments  to  “Mul”  are  possible.  The  second  production 
is  the  bridge  production.  "Rval"  is  a  non-terminal 
corresponding  to  any  general  operand,  and  conse¬ 
quently  any  integer  expression  which  could  be  com¬ 
puted  into  e  register,  so  "rval”  will  eever  the  evalua¬ 
tion  of  subtrees  other  than  multiplication  by  four. 

Syntactic  Mocks  can  be  detected  automatically 
by  the  table  constructor  (|3.2).  although  when  we 
developed  the  grammar,  this  part  of  the  table  con¬ 
structor  was  disabled  for  trivial  implementation  rea¬ 
sons.  We  found  it  satisfactory  to  inspect  tbs  dense 
action-next  tables  for  error  actions;  we  had  no 
surprises  when  we  re-enabled  the  automatic  chock. 
The  semantic  actions  for  bridge  productions  can  be 
synthesised  automatically  from  real  Instructions, 
although  wo  also  did  that  by  band.  (The  automatic 
techniques  are  discussed  in  [QenvillsTfl].) 

We  do  not  yet  have  a  theory  explaining  what  the 
unshared  part  of  the  bridge  production  should  be.  In 
the  example  above,  we  chose  the  recursive  non¬ 
terminal  ”rvai";  the  recursive  non-terminal  "reg" 
would  have  covered  the  block  as  welL  When  the  gram¬ 
mar  is  written  It  la  difficult  to  predict  which  choice  for 
tbo  covering  non-terminal  produces  better  code. 


Our  VAX  description  bas  no  instances  of  semantic 
blocking.  Only  one  situation  arose  in  which  semantic 
Mocking  might  have  occurred.  Since  the  default  list 
construction  mechanism  in  CGGWS  was  disabled  when 
we  developed  the  code  generator,  we  ion  verted  the 
semantic  block  to  a  syntactic  Mock,  which  was  then 
resolved  by  bridge  productions.  We  describe  this  case, 
because  it  appears  to  represent  a  more  general  sort  of 
choice  between  syntax  and  semantics. 


ln  its  simplest  form,  semantic  blocking  can  arise 
in  describing  the  addressing  modes  of  the  VAX  because 
the  hardware  incorporates  typed  addressing.  For 
example,  the  general  form  of  the  address  computed  by 
displacement  indexing  is: 


dx  -  Plus  Plus  Const  reg  Mul  Const  reg 
where  the  "Const"  left  cMld  to  the  “Mul"  operator  is 
semantically  restricted  to  be  1,  2,  4  or  B  (correspond¬ 
ing  to  byte,  word,  long  or  double  word  addressing).  If 
the  second  “Const”  is  not  1.  2,  4  or  6.  a  sequence  of 
instructions  must  be  generated.  To  avoid  semantic 
Mocking,  we  introduce  the  syntactic  tokens  “One", 
"Two",  "Four",  and  "Eight”  in  place  of  the  second 
"Const”  when  describing  the  addressing  mode.  The 
resulting  syntactic  block  is  resolved  with  a  bridge  pro¬ 
duction.  as  discussed  in  the  previous  section. 

The  replacement  of  the  semantic  constraint  by  a 
syntactic  one  potentially  reduces  the  power  of  the 
code  generator.  Now.  the  special  constants  will  be 
discovered  only  if  they  were  converted  to  syntactic 
tokens  when  the  input  was  generated.  That  might  not 
be  done  for  every  occurrence  of  those  constant  values. 
On  the  other  band,  it  may  be  faster  to  handle  these 
cases  syntactically,  rather  than  semantically.  This 
issue  merits  further  investigation. 


•  4.  Data  Types  and  Type  Conversion 

The  expression  trees  input  to  the  code  generator 
consist  of  generic  operators  attributed  with  the  data 
type  of  the  resulting  value.  Other  attributes  to  the 
operators  or  operands,  such  as  the  binding  of  a  dedi¬ 
cated  register,  need  not  concern  us  here.  With  the 
exception  of  the  dereferencing  operator  and  the 
incomplete  set  of  conversion  operators,  the  operands 
must  be  converted  to  have  the  same  type  as  the 
expected  result  before  the  operation  can  be  per¬ 
formed.  This  reflects  the  semantics  of  "C".  Pascal  and 
Fortran,  as  well  as  the  conventions  of  the  hardware. 
However,  in  the  incoming  expression  trees,  the 
operands  have  their  own  data  types,  which  need  not 
agree  with  the  deta  type  of  the  operator.  The  "front 
ends"  rarely  generate  the  conversion  operators. 

In  this  experiment  we  did  not  cheek  any  semantic 
attributes  in  the  expression  tree  as  a  condition  to 
selecting  among  productions  in  a  rwdaoa/roduoo 
conflict,  nor  did  we  have  the  related  mechanism  for 
default  list  construction  and  application  that  the  basic 
Craham-Glanvtlle  algorithm  uses.  Consequently,  we 
had  to  use  syntax  to  insure  that  the  type  of  the  actual 
operands  correctly  matched  the  expected  type  of  the 
formal  operands,  and  that  appropriate  conversion 
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instructions  war*  generated.  This  tjrpa  watching  la 
nooossary  before  tha  instruction  tabla  ( (ft. 3.1)  is 

In  order  to  imp  lam  ant  tjrpa  checking  and  type 
conversion  syntactically.  every  symbol  that  can  pent* 
My  bars  n  different  type  attributes  must  be  raplaead 
by  «  different  symbols,  on*  for  each  type.  In  addition, 
the  special  constants  0,  1.  8,  4  and  t  must  have  tboir 
asm  terminal  symbols,  baoaus*  of  the  importune*  they 
play  in  comparisons  and  address  construction. 

As  a  consequence  of  “syntax  for  semantics'*,  wo 
bee*  separate  instruction  patterns  tor  each  machine 
type  for  which  tha  operation  is  defined,  elaborating 
tfaesa  new  symbols  and  productions  by  band  is  tedious 
and  error  prone.  Instead,  we  write  generic  operators, 
operands  and  productions,  and  use  a  macro  preproces¬ 
sor  to  type  ropUeafe  the  generic  grammar,  yielding  tbs 
final  grammar  from  which  the  tables  arc  constructed. 
The  macros  are  three  eharaetera  long.  The  first  and 
third  characters  are  identical,  and  tersely  specify  the 
set  of  machine  date  types  permitting  replication.  The 
second  obaraetor  specifies  which  repUoaUon  operator 
is  to  be  applied. 

For  example,  a  generic  production  deaeriMag  the 
addrees  computed  by  displacement  indexing,  the 
example  used  in  |B.2.Z,  is  shown  here*: 

dx_|T#  a  Plus _1  Plus _1  Const  ragj  Mul_l  #V#  reg_l  9(f) 

The  character  "f  indicates  that  the  four  machine 
types  with  different  date  sixes  are  valid;  the  Mass  char¬ 
acters  **T"  and  “V*  expand  to  a  typo  specific  suffix 
character  and  constant,  respectively.  Type  replication 
yields: 

dx_b  *  Plua_l  Plus.l  Const  reg_l  Mul_l  One  r*g_l  9(7) 
dx_w  -  Ptus_l  Plus_l  Const  reg_l  Mul_l  Two  reg_l  HT) 
dx_l  Ptus_l  Ptus.l  Const  reg_l  Mul.l  four  reg_l  HIT) 
dx_d  a  Plus J  PlusJ  Const  rag_l  Mul_l  light  r*g_l  9(f) 

Type  replication  baa  three  drawbaeks  in  our 
tmpie  mentation.  First,  the  sixe  e(  the  final  grammar  is 
enormous.  Second,  the  type  rephoator  only  works  on 
productions  whooe  intra  production  type  variation  is 
oonslstont;  it  ean  not  automatically  expand  date  type 
arose  products  to  areata  the  sub-grammar  describing 
the  date  conversion  Instructions.  V*  performed  this 
ores*  product  by  hand  and  tntrodueed  several  errors. 

Tfce  third  problem  with  typo  replication,  as  w* 
implemented  it,  ia  the  intertooe  between  the  grammar 
and  the  routines  that  encapsulate  semantics.  The 
interface  la  constrained  by  the  Amotion  ean  to  "X” 
that  takes  a  single  argument,  a  band  assigned  produc¬ 
tion  number.  This  restricted  eall  to  “It”  is  caused  by 
bad  design  In  the  grammar  specification  language,  and 
ia  not  an  Inherent  problem  with  our  code  generation 
technique. 

It  is  clear  that  putting  type  constraints  back  into 
the  semantic  constraints  would  make  the  description 
smaller.  What  is  loss  doer  is  the  effect  that  would  have 
on  the  speed  of  the  code  generator,  states  semantic 


cheeking  is,  ia  effect,  interpretive.  We  intend  to 
explore  that  tbne/spaee  tradeoff. 

Moot  of  the  operators  forming  the  intermediate 
expression  trees  were  easily  implemented  on  the  VAX. 
oa  it  was  easy  to  describe  moot  of  the  VAX  instructions, 
operands  and  data  types.  For  o  number  of  reasons,  we 
bad  implementing  operators  manipulating 

structures,  fields,  and  unsigned  numbers.  The  biter- 
mediate  trees  are  both  undocumented  and  poorly 
suited  to  expressing  structures  and  fields.  Sains  of 
these  proMems  would  go  away  if  we  introduced  new 
operators  in  tho  trees,  spent  mere  time  eaaonicalisbig 
tbs  tree  before  pattern  matching,  and  redesigned 
some  semantic  routines. 

The  “C"  language  compound  assignment  opera¬ 
tors,  such  as  "4o*‘,  are  expanded  by  the  tree  rewriter 
in  tbs  first  phase.  For  example,  tha  "C"  statement 
a+*b 
becomes: 

aa  a  ♦  b 

Belters  “a"  is  treated  aa  a  common  aub  expression,  it  ia 
(breed  to  be  directly  addressable.  This  transformation 
introduces  additional  operators  and  requires  mechan¬ 
isms  in  tba  third  phase  to  define  and  reference  a 
locally  scoped  common  aub  expression  corresponding 
to  an  address.  This  rewriting  rule  ia  compatible  with 
our  algorithm  tor  finding  binding  idioms,  as  the  assign¬ 
ment  operator  is  first  coded  aa  a  three  address 
instruction,  and  then  transformed  into  a  two  address 
instruction.  Unfortunately,  assignment  operators  not 
implemented  by  the  hardware  in  one  Instruction,  such 
as  unsigned  division,  are  not  bandied  well  by  our 
model.  Our  only  reason  for  performing  this  transfor¬ 
mation  was  to  minimise  the  number  of  patterns  in  the 
machine  grammar,  as  wo  did  not  want  to  maintain 
separate  patterns  tor  variants  of  the  same  hardware 
instruction.  In  retrospect,  the  problems  we  created 
were  much  harder  to  solve  correctly  than  those  we 
avoided. 

We  spent  inordinate  amounts  of  time  writing  and 
testing  expressions  that  esarcis*  the  union  of  problem 
areas  in  our  code  generator.  As  a  bonus,  we  also  found 
bugs  in  tho  portable  ”C*  compiler.  The  complicated 
expressions  we  Invented  ean  not  be  expressed  in  Pas- 
eal  or  Fortran  77.  Our  favorite  was  an  expression  with 
chained  unsigned  assignment  division  operators  on 
auto  Incremented  bit  field  operands! 

Wo  developed  our  code  generator  over  approxi¬ 
mately  a  year  of  part-time  work.  (Some  of  this  time  was 
spent  improving  the  table  generator.)  X  X  Henry  origi¬ 
nally  developed  the  code  generator  to  ehaclc  some 
hypotheses  oooeeralng  grammar  factorisation.  The 
machine  description  grammar  was  (but  written  only  for 
long  date  types  ahd  tho  easily  implemented  instruc¬ 
tions,  but  included  afi  addressing  modes.  When  the  fac¬ 
toring  h  >othe**s  wore  empirically  verified,  we  began  to 
Otter *  jo  eodo  generator  so  that  tt  eoutd  generate 
eo*  m  interesting  programs.  X  took  us  several 
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iterations  before  we  discovered  the  algorithms  to 
trensform  end  eanooieallso  tree*. 

It  Sebuiman  re-wrote  the  grammar  and  ■  emu  tic 
action*  to  instruction  (election  wai  data  type  sensitive. 
Thie  addition  wee  compounded  by  poorly  underetood 
inter-production  interaetiono  eaueed  by  overfaetoring. 
Vo  alto  ebangod  the  eimple  regieter  meneger  to  allo¬ 
cate  double  regieters  and  to  tpill  and  unepill  regieten. 
Adding  etructure  assignment  and  field  operator! 
effected  all  eub-pbaeet  In  the  code  generator,  meet  not¬ 
ably  the  inetruetion  generator. 

In  the  last  etagea  of  development  we  became 
bagged  down  became  it  required  over  two  memory- 
in  to  naive  boura  of  VAX  11/790  CPU  time  to  eonatruct  a 
new  aet  of  tablet  from  the  enormout  machine  descrip¬ 
tion  grammar.  Since  we  could  only  iterate  on  the  gram¬ 
mar  once  per  day.  we  removed  huge  by  modifying  the 
grammar  only  ae  a  laat  retort.  Nevertheless,  the  table 
constructor  wee  run  more  than  225  timet  during 
development  aim  oat  always  for  a  date-type  lubaatted 
description  grammar.  Subsequently,  we  have  developed 
new  techniques  which  speed  up  the  table  constructor 
dramatically. 

Because  the  code  generator  was  developed  by 
"augmentation”,  instead  of  by  a  rind  plan,  and  the 
grammar  developed  by  "avoidance",  the  internal 
semantics  have  many  rough  edges.  Ve  gave  no  thought 
to  speed  when  coding  the  semantics,  and  find  that  the 
code  generator  runs  slightly  slower  than  the  portable 
"C”  compiler. 

a  Cede  Generator  Statistics 

Our  generic  machine  description  grammar  tor  the 
VAX.  before  type  replication,  has  458  productions,  115 
terminals  and  °8  non-terminals.  After  type  replication, 
the  final  grauunar  has  1073  productions,  219  terminals, 
and  149  non-terminals,  and  yields  u  instruction  selec¬ 
tor  with  2219  states*. 

Our  code  generator  spends  most  of  its  time  pars¬ 
ing.  Thie  reflects  both  the  large  number  of  chain  pro¬ 
ductions  in  the  grammar,  and  Urn  time  spent  manipu¬ 
lating  and  unpacking  the  description  tables.  Many  of 
the  chain  productions  ore  a  consequence  of  the  syntac¬ 
tic  treatment  of  machine  data -type  conversion.  The 
Appendix  shews  the  actions  the  paraer/pattern  matcher 
makes  when  generating  code  for  a  eimple  Pascal  state- 
Viont. 

Our  code  generator  produces  code  that  passes  vali¬ 
dation  suites  tor  "C",  for  Pascal  and  for  Fortran77, 
although  there  are  still  subtle  bugs  involving  conversion 
between  signed  end  unsigned  data  types.  For  e  particu¬ 
lar  large  "C“  program,  our  code  generator  generates 
eode  in  90.1  seconds,  compared  with  the  55.4  seconds 
the  portable  "C  compiler  spends'.  Our  coder  produces 
11395  lines  of  assembly  eode;  PCC  produces  11399  lines. 
Although  we  have  not  done  any  statistical  comparisons, 
it  appears  that  the  eode  generated  by  our  program  is  as 
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good  or  better  than  that  produced  by  the  portable  "C" 
compiler  In  almost  all  eases. 

Naturally,  our  restricted  eode  generation  model 
effects  the  quality  of  coda  we  produce  We  could  not 
change  the  "front  ends"  of  the  ”C“.  Pdecal  or  Fortran 77 
compilers,  nor  could  wa  change  the  existing  peephole 
opUmitsr  or  assembler  that  further  process  tbs  assem¬ 
bly  eode  the  eode  generator  produces.  We  do  not  per¬ 
form  data  flew,  or  common  tub-expression  analysis,  or 
any  non-local  code  improvement.  Finally,  we  omitted 
certain  instructions  from  our  machine  description,  such 
as  the  loop  instructions. 

We  have  not  yet  had  any  experience  retargeting 
this  compiler  to  other  machines.  We  feel  that  the  tech¬ 
niques  to  factor  the  machine  grammar  can  be  applied 
to  a  new  machine.  In  a  new  implementation,  we  would 
reconsider  our  decision  to  type  operands  syntactically, 
a  convention  which  greatly  increases  the  site  of  the 
grammar. 

We  see  two  primary  benefits  of  this  experiment. 
First,  in  our  experience,  using  a  pattern  matcher  in  a 
production  compiler  provides  a  well  understood  model 
for  instruction  matching.  The  pattern  matcher  is  a  con¬ 
venient  place  to  encapsulate,  in  a  wall  understood  way. 
almost  all  the  knowledge  about  instruction  patterns. 

The  experiment  hes  also  pointed  up  some  of  the 
important  issues  to  pursue  in  developing  this  method 
further.  We  have  already  improved  our  algorithms  tor 
table  construction  so  that  the  computation  for  our  com¬ 
plete  VAX  description,  which  used  to  take  over  two 
hours,  now  takes  ten  minutes.  We  are  investigating  the 
tradeoffs  between  syntactic  and  semantic  treatment  of 
attributes.  In  that  connection,  we  are  studying  the  best 
way  to  use  the  formalised  attribute  processing  pro¬ 
posed  by  [Canape thiSO].  We  are  also  examining  ways  to 
recognize  and  handle  situations  in  which  maximal 
munch  is.  within  our  eode  generation  model,  sub- 
optimal.  We  are  examining  the  interaction  between 
pattern-directed  code  generation  with  flew  analysis  and 
optimisation,  and  the  interface  between  our  method  for 
table-driven  code  generation  and  peephole  optimisa¬ 
tion. 
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Stuart  Feldman.  Dan  Halbert.  Peter  Kessler. 
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able  comments  on  early  drafts  of  this  paper. 
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It.  ACmptoU  Cade  Generation  faempia 

This  appendix  shows  the  cede  our  eodt  (antra tor  produeoa  for  the  "example 
ospraaaion"  in  thif  Incomplete  Paaeal  program. 

program  eppendix( output); 

ear  a:  Integer.  {  aioved  at  a  global  name  { 

procedure  foo; 

ear  b:  -128  ..  127;  f  stored  in  tea  from*  | 

kegte 


a :»  27  ♦  b  i  a  sample  eaproaaion  | 

end: 
begin 

foo 

and 


The  flret  past  of  Um  Berkeley  Paaeal  compiler  turn*  the  example  expreaaion  into  an 
intermediate  tree  with  this  linearised  prefix  representation.  The  tree  transformation 
phase  does  nothing  with  the  tree,  so  it  is  passed  to  the  pattern  matcher  "as  is". 


Assign.! 

Name  1:  "a" 
PlusJ 

Conat.b:  “27" 
Indir.b 
PlusJ 
Const.b:  "b 
DregJ:  "fp' 


sa 


long  assignment 
long  global  name 
long  addition 
byte  constant 
indirection  to  fetch  a  byte 
address  (long)  addition 
byte  constant 
long  dedicated  register 


The  code  generator  performs  the  following  sequences  of  shift,  naduee.  and  accept 
actions  whan  generating  code  for  the  example  expression. 


action 

shift 

shift 


shift 

shift 

shift 


shift 

shift 

shift 

ahlft 

reduce 


ahlft 

shift 

reduce 

reduce 

reduce 


namej  ■* 

“otypaj’eiij  « 

notype  Jval.l  -• 
lval.l  - 


conat.b  - 
eonst.w  4 
conat.l  4 


const.b 

eonst.w 

eonst.l 


sreg_t 

reg_l 

diap 

am.uncon.b 
am.b 
notype.rval.b 
nr  al.b 

*»«J 

notype.rvali.l 

notype.nral.l 

nrai.l 

aag.tree.1 

c.trees 

tree 


on  what 
Asaignj 

Name.! 

Name.l 

name.l 

notypejvali.l 

notypa.lTal.l 

hrsl.I 

PlusJ 

Const.b 

Const.b 

eonst.b 

eonst.w 

eonst.l 

lndlr.b 

PlusJ 

Const.b 

Conat.b 

const.b 

eonst.w 

eonst.l 

DregJ 

DregJ 

sreg.1 

Plus. I  eonst.l  rsgj 
disp 

am.uncon.b 
lndlr.b  am.b 
notype.rrai.b 
rral.b 
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